Agent 实战
教科书的 3 步 vs 真实的 N 步
教科书说 Agent 循环是「想→做→看」三步。但当你真正把 Agent 推上生产环境，每转一圈要做的事比你想象的多得多。
教科书版 vs 真实版
教科书版 ReAct
1
Think — 思考下一步该做什么
2
Act — 调用一个工具
3
Observe — 拿到结果，决定下一步
循环直到任务完成
⚙️ 真实生产版（单轮）
为什么多出来这么多？
教科书省略的部分，恰恰是让 Agent 稳定、安全、可用的关键：
- 上下文压缩 — 对话越来越长，不裁剪就会超出窗口
- 权限校验 — 这个工具用户有没有权限调？参数合不合法？
- 并发调度 — 多个工具能同时跑吗？怎么协调？
- 错误处理 — 工具超时了怎么办？返回格式错了怎么办？
- 结果回写 — 执行结果要写回上下文、更新状态、触发通知
- 安全审计 — 记录每一步操作，以防出问题可追溯
真实的 Agent 每转一圈，要做的事比你想的多 5 倍。教科书的 3 步只是骨架，生产环境的每一轮循环里藏着权限、压缩、容错、审计等大量隐藏逻辑，这些才是 Agent 工程的核心工作量。
Agent 实战
为什么 Agent 会卡死
实验室里的 Agent 死循环很好发现：控制台一刷就看到了。但生产环境的卡死更隐蔽：用户不会说「你的 Agent 死循环了」，他只会说「你的 AI 怎么这么慢」或者「它是不是傻了」。
四种生产环境特有的卡死模式
同参数死循环
Agent 连续 3 次用完全相同的参数调用同一个工具
模型忘了上次已经做过这件事，或者认为上次没成功所以要重试，但参数一模一样，结果也一模一样。
用户看到的表现
「它转了好久都没反应」「怎么一直在加载」
典型场景：反复读取同一个文件、反复搜索同一个关键词、反复调用同一个 API
收益递减
跑了 50 轮循环，但几乎没产出有价值的内容
Agent 在忙，但每一轮只做边缘操作：整理格式、反复确认、做无关搜索。看起来在工作，实际没有推进核心目标。
用户看到的表现
「等了两分钟，结果就给我这？」「AI 是不是在划水」
典型场景：Agent 在复杂任务中迷失方向，不断做安全但无用的小动作
文本复读
模型开始重复自己说过的话，一段内容反复出现
当上下文过长或模型困惑时，它会退化为复读模式：把之前的输出再生成一遍。模型并没有卡住，它已经迷路了。
用户看到的表现
「它在说车轱辘话」「怎么又是这段」
典型场景：长对话后期、上下文接近窗口上限、任务描述模糊
工具连续失败雪崩
一个工具挂了，Agent 疯狂重试，拖垮整条链路
工具 A 超时 → Agent 重试 → 还是超时 → 换个方式调 → 还是不行 → 试工具 B 来绕过 → B 依赖 A 的结果也挂了 → 雪崩。
用户看到的表现
「它好像卡住了」「等了好久突然说失败了」
典型场景：外部 API 限流、数据库连接池耗尽、第三方服务临时宕机
模拟：卡死现场
选择一种模式，看后台日志长什么样
← 选择一种模式开始模拟
生产环境的 Agent 挂法和实验室里不一样：用户不会告诉你「Agent 死循环了」，他只会说「你的 AI 怎么这么慢/这么蠢」。识别这些模式，是做防护的前提。
Agent 实战
防呆设计：怎么让循环自己停下来
知道了 Agent 会怎么卡死，下一步就是设计防护。好的防呆是三层网，让系统既不会失控，又不会轻易放弃。
三类防护策略
硬限制
无条件的刹车，不管什么情况都会触发
迭代上限
设定最大循环次数（如 50 轮），到了就强制停止。简单粗暴但有效，是最后一道防线。
展开
总超时
设定任务最大执行时间（如 3 分钟）。不管跑了多少轮，超时就中断，防止无限占用资源。
展开
单工具次数上限
同一个工具最多调用 N 次（如同一接口最多 5 次）。防止 Agent 对一个工具上瘾。
展开
检测类
监控运行状态，发现异常模式时发出预警
同参数检测
检测连续 N 次是否用完全相同的参数调用同一工具。如果是，说明 Agent 在原地打转。
展开
同工具名检测
最近 N 轮是否只在调同一个工具。如果是，可能陷入了执念，需要引导它换条路。
展开
收益递减检测
对比最近几轮的产出增量。如果跑了 10 轮但新内容不到 50 字，判定为低效空转。
展开
降级类
带伤继续或优雅退出，先不直接停
注入纠错提示
在上下文中注入一条系统消息：「你已经重复了 3 次，请换一种方法」，让模型自己调整策略。
展开
禁用故障工具
某工具连续失败时，从可用列表中暂时移除。逼迫 Agent 走其他路径完成任务。
展开
强制总结当前进度
触发条件时，强制 Agent 总结当前已做的事、已得到的结果，带着残缺的进度返回用户。
展开
三层防护的层次关系
防呆不是一道墙，是三层网
降级类 — 优雅续命，尽量完成任务
发现异常 → 尝试自救
检测类 — 及时发现，提前预警
监控模式 → 触发降级
硬限制 — 最后兜底，绝对不失控
无条件刹车 → 保证安全
设计原则：先让降级尝试自救 → 自救失败由检测上报 → 最终由硬限制兜底。
大多数情况下，Agent 应该被温柔地纠正，粗暴杀死是下策：对用户来说，带着半成品回来比空手而归好得多。
大多数情况下，Agent 应该被温柔地纠正，粗暴杀死是下策：对用户来说，带着半成品回来比空手而归好得多。
防呆不是一道墙，是三层网：硬限制兜底、检测预警、降级续命。好的防护设计让 Agent 既不会失控，又不会轻易放弃，尽可能带着成果回来。
Agent 实战
流式体验：别让用户干等
Agent 在后台跑了 30 秒，用户屏幕上应该看到什么？同样是等 30 秒，有没有进度感，体验天差地别。
对比：有 vs 没有进度感
✗ 没有进度感
有进度感
进度感设计三原则
让用户看见过程
别只给一个转圈，要展示正在做什么：搜索中、分析中、整理中
让进度可感知
「找到 3 条结果」「已分析 2/5 个文件」，有数字、有变化、有推进感
让输出渐进出现
让文字逐字流出：流式输出本身就是最好的进度条
常见的进度感手段
| 状态文案 | 「正在搜索相关信息...」 → 「找到 5 条结果，正在分析...」 |
| 工具展示 | 把正在调用的工具名和参数展示给用户，让他知道 AI 在做什么 |
| 流式输出 | 模型生成的文字逐 token 显示，让等待变成阅读 |
| 阶段标记 | 「第 1 步 / 共 3 步」，即使无法精确预估，分阶段也比不分好 |
| 中间产物 | 先给一个粗略结果，再逐步精化：比如先给大纲，再填充细节 |
用户能忍受等待，但不能忍受「不知道在等什么」。进度感 ≠ 进度条。进度感的核心是让用户觉得「AI 在认真干活」，不让他对着空白屏幕怀疑人生。
Agent 实战
一条消息背后的真实成本
用户只发了一句话，但底层可能跑了 10+ 轮循环、产生几十条 API 消息。当你打开账单，可能会吓一跳。
选一个用户消息，看背后发生了什么
模拟用户发送的消息：
成本随复杂度指数增长
成本的大头在哪里？
• System Prompt — 每轮都要重复发送，轮次越多重复消耗越大
• Tool Results — 工具返回的文本通常很长（整个文件内容、搜索结果...）
• 上下文累积 — 后面的轮次要带上前面所有消息，滚雪球式增长
• System Prompt — 每轮都要重复发送，轮次越多重复消耗越大
• Tool Results — 工具返回的文本通常很长（整个文件内容、搜索结果...）
• 上下文累积 — 后面的轮次要带上前面所有消息，滚雪球式增长
你的用户每说一句话，你的账单上可能多了 10 美分。知道成本在哪里，才能控制成本。Agent 的成本随轮次指数增长，远超线性：每一轮都要把之前所有内容重新发送给模型。